IntroductionThe Web works because it is simple. HTTP is simple. HTML is simple. 
Scripting languages such as ECMAScript are simple. 
Simplicity does not mean low functionality. To the contrary, the dizzying array 
of applications and services that are emerging on the Web work only to the 
degree that they maintain the simplicity and the strict standards that make them 
available to the largest possible audience regardless of client platform.
To date there have been a number of efforts to adopt solutions from the 
client-server world to build distributed applications that work over the Web. 
But client-server follows a fundamentally different model of distributed 
computing based on using Remote Procedure Calls (RPC) to invoke objects in 
distant applications. 
RPC-based approaches to distributed computing are highly efficient and provide 
control for developers over all aspects of communication and state management. 
But the RPC distributed object model is more difficult and is expensive in terms 
of development time and resources. In addition, distributed object frameworks 
such as COM, CORBA and Java's Remote Method Invocation (RMI) require dedicating 
future development to the same framework to ensure interoperability. They can 
work alongside the Web, but they lack the transparency, simplicity and broad 
scope that made the Web successful.
A similar problem has emerged at the server. With the proliferation of 
application servers and frameworks, the transparency of HTTP is compromised by 
application-specific data structures that make communication between different 
vendors' servers difficult, if not impossible. 
While it is important to use the fundamental advantage of client-server that 
these approaches bring to the Webnamely the sharing of processing power between 
client machines, when available, and different tiers of servers to enable higher 
scalability of distributed web appsthe approach to these problems must also 
follow the model that makes the Web work or the Web will collapse under 
increasing complexity. 
At the same time, one would like to move away from the world in which web 
application servers and browsers are separated by the walls imposed by 
under-powered data exchange mechanisms to a world where web applications execute 
on the entire network. The key to solving each of these problems is providing a 
mechanism for exchanging structured data in a generic, cross-platform and 
Web-friendly way. 
Meeting the Challenge With WDDX 
WDDX overcomes the challenges described above by providing a flexible, open and 
pragmatic way to solve the problem of structured data exchange in web 
applications. Very simply, WDDX is a mechanism for exchanging complex data 
structures between application environments. WDDX consists of a language and 
platform neutral representation of instantiated data based on XML 1.0 and a set 
of modules that translate native language environment data structures into XML 
and vice versa. 
The usefulness of WDDX is best demonstrated with an example. A common use is 
server-to-server data exchange. For example, a ColdFusion order tracking web 
application could consume WDDX data produced by FedEx's Perl-based package 
tracking web application thus integrating package tracking and delivery 
confirmation into the corporate order tracking process across the Internet. This 
is one of many examples. (See below for other scenarios.)
WDDX does not replace the need for other XML vocabularies. However, it can 
transform the heterogeneous direction of distributed web applications into a 
more seamless, interoperable environment.
While WDDX packets are human readable because they are XML documents, it is 
expected that applications will use the format as a wire protocol only. This 
means that many developers who would otherwise not have time or inclination to 
learn to build XML can be brought into the fold. What's more, for interactions 
between web-based services that may have slower or different adoption rates and 
strategies for XML, WDDX provides a baseline that all applications can depend on 
when transmitting structured information. It is a bootstrap technology. Once the 
advantages of interoperability are apparent, it will be easier to convert the 
broad base of developers to supporting the full potential of XML.
WDDX vs. Other Approaches
Because of the explosion of approaches to problems related to those that WDDX 
seeks to solve, it is extremely important to outline what the proposal is meant 
to solve. It is perhaps easiest to do this by contrasting it with a number of 
other technologies, proposals and strategies that have emerged in recent months.
WDDX, XML and the DOM 
Conceptually, WDDX overlaps some of the general goals of XML. In particular, the 
idea of arbitrarily moving structured data between applications would seem to be 
handled by the larger framework of validating parsers being able to extract 
information from structured documents regardless of their origin.
While this is true in the abstract, much of the required infrastructure for 
typing data and validating structures is a valuable addition to the general 
portability of XML. WDDX can be thought of as a very-high level API built on top 
of the DOM. For all XML data not based on the WDDX DTD DOM processing makes the 
most sense. 
WDDX, SOAP and WebBroker 
WDDX isn't about objects. WDDX is a mechanism for structured data exchange. It 
cannot be used in object-oriented scenarios to exchange object instances that 
have some complex interrelations. It is not well suited as a backbone technology 
for distributed object applications running on the Web. DataChannel's WebBroker 
and Microsoft's Simple Object Access Protocol (SOAP) are more appropriate for 
this task.
WDDX and WIDL 
WDDX is an XML vocabulary for representing application-level data structures in 
a portable, text-based format. It offers no facilities for structured data 
extraction/generation. Much of webMethods's Web Interface Definition Language 
(WIDL) is about the extraction of information from unstructured sources such as 
HTML pages. 
WDDX and RDF 
A WDDX XML data packet is a structurally equivalent representation of some 
application-level data structures. WDDX provides no mechanism via which the 
contents of its packet can be described or validated against some notion of what 
a "valid" data packet is. Therefore, WDDX is not related to RDF (Resource 
Description Framework) and does not use any of its capabilities. 
WDDX and Datasource Objects 
XML DSOs appeared in IE4 as a means for representing XML data in a tabular 
format. XML DSOs consume XML data and expose it as something similar to a 
recordset object for data binding. The WDDX XML format is used only internally 
(between the WDDX serializer and deserializer objects). Therefore, datasources 
that produce some generic XML documents cannot be used with WDDX. 
WDDX and XML DTDs
WDDX abstracts the process of DTD creation, XML data production, and XML data 
parsing for application-level data exchange. WDDX's timing is excellent because 
currently (a) there aren't many native XML datasources on the Web, (b) 
developers lack knowledge of XML, and (c) currently, most interesting data lives 
in some form of application data structures at some point, e.g., in a recordset 
before becoming a report web page. In the long run, many datasources will 
benefit from exposing some form of native non-WDDX XML interfaces for a variety 
of reasons, e.g., validation, publishing, etc. 
WDDX and Traditional RPC-based Systems 
As discussed in the introduction, the primary goal of WDDX is to provide a more 
Web-like way to transmit structured data objects between network entities 
without changing the programmatic approach to developing web applications from 
page-based to object-based. The following table outlines the primary attributes 
of each approach.
<?xml version='1.0'?><!DOCTYPE wddxPacket SYSTEM 'wddx_0090.dtd'>
<wddxPacket version='0.9'>
    <header/>
    <data>
        <struct>
            <var name='s'>
                <string>a string</string>
            </var>
            <var name='n'>
                <number>-12.456</number>
            </var>
            <var name='d'>
                <dateTime>1998-06-12T04:32:12</dateTime>
            </var>
            <var name='b'>
                <boolean value='true'/>
            </var>
            <var name='a'>
                <array length='2'>
                    <number>10</number>
                    <string>second element</string>
               </array>
            </var>
            <var name='obj'>
                <struct>
                    <var name='s'>
                        <string>a string</string>
                    </var>
                    <var name='n'>
                        <number>-12.456</number>
                    </var>
                </struct>
            </var>
            <var name='r'>
                <recordset rowCount='2' fieldNames='NAME,AGE'>
                    <field name='NAME'>
                        <string>John Doe</string>
                        <string>Jane Doe</string>
                    </field>
                    <field name='AGE'>
                        <number>34</number>
                        <number>31</number>
                    </field>
                </recordset>
            </var>
        </struct>
    </data>
</wddxPacket>

      It defines a root level object that is a structure (also known as an 
      associative array) of six properties:

